<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.4"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>Flow-IPC: shm/shm_fwd.hpp Source File</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr id="projectrow">
  <td id="projectalign">
   <div id="projectname">Flow-IPC<span id="projectnumber">&#160;2.0.0</span>
   </div>
   <div id="projectbrief">Flow-IPC project: Full implementation reference.</div>
  </td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.9.4 -->
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search",'Search','.html');
/* @license-end */
</script>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
  initMenu('',true,false,'search.php','Search');
  $(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
     onmouseover="return searchBox.OnSearchSelectShow()"
     onmouseout="return searchBox.OnSearchSelectHide()"
     onkeydown="return searchBox.OnSearchSelectKey(event)">
</div>

<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0" 
        name="MSearchResults" id="MSearchResults">
</iframe>
</div>

<div id="nav-path" class="navpath">
  <ul>
<li class="navelem"><a class="el" href="dir_ddb0f12d0722949f40b2818843b69123.html">shm</a></li>  </ul>
</div>
</div><!-- top -->
<div class="header">
  <div class="headertitle"><div class="title">shm_fwd.hpp</div></div>
</div><!--header-->
<div class="contents">
<a href="shm_2shm__fwd_8hpp.html">Go to the documentation of this file.</a><div class="fragment"><div class="line"><a id="l00001" name="l00001"></a><span class="lineno">    1</span><span class="comment">/* Flow-IPC: Shared Memory</span></div>
<div class="line"><a id="l00002" name="l00002"></a><span class="lineno">    2</span><span class="comment"> * Copyright 2023 Akamai Technologies, Inc.</span></div>
<div class="line"><a id="l00003" name="l00003"></a><span class="lineno">    3</span><span class="comment"> *</span></div>
<div class="line"><a id="l00004" name="l00004"></a><span class="lineno">    4</span><span class="comment"> * Licensed under the Apache License, Version 2.0 (the</span></div>
<div class="line"><a id="l00005" name="l00005"></a><span class="lineno">    5</span><span class="comment"> * &quot;License&quot;); you may not use this file except in</span></div>
<div class="line"><a id="l00006" name="l00006"></a><span class="lineno">    6</span><span class="comment"> * compliance with the License.  You may obtain a copy</span></div>
<div class="line"><a id="l00007" name="l00007"></a><span class="lineno">    7</span><span class="comment"> * of the License at</span></div>
<div class="line"><a id="l00008" name="l00008"></a><span class="lineno">    8</span><span class="comment"> *</span></div>
<div class="line"><a id="l00009" name="l00009"></a><span class="lineno">    9</span><span class="comment"> *   https://www.apache.org/licenses/LICENSE-2.0</span></div>
<div class="line"><a id="l00010" name="l00010"></a><span class="lineno">   10</span><span class="comment"> *</span></div>
<div class="line"><a id="l00011" name="l00011"></a><span class="lineno">   11</span><span class="comment"> * Unless required by applicable law or agreed to in</span></div>
<div class="line"><a id="l00012" name="l00012"></a><span class="lineno">   12</span><span class="comment"> * writing, software distributed under the License is</span></div>
<div class="line"><a id="l00013" name="l00013"></a><span class="lineno">   13</span><span class="comment"> * distributed on an &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR</span></div>
<div class="line"><a id="l00014" name="l00014"></a><span class="lineno">   14</span><span class="comment"> * CONDITIONS OF ANY KIND, either express or implied.</span></div>
<div class="line"><a id="l00015" name="l00015"></a><span class="lineno">   15</span><span class="comment"> * See the License for the specific language governing</span></div>
<div class="line"><a id="l00016" name="l00016"></a><span class="lineno">   16</span><span class="comment"> * permissions and limitations under the License. */</span></div>
<div class="line"><a id="l00017" name="l00017"></a><span class="lineno">   17</span><span class="comment"></span> </div>
<div class="line"><a id="l00018" name="l00018"></a><span class="lineno">   18</span><span class="comment">/// @file</span></div>
<div class="line"><a id="l00019" name="l00019"></a><span class="lineno">   19</span><span class="comment"></span><span class="preprocessor">#pragma once</span></div>
<div class="line"><a id="l00020" name="l00020"></a><span class="lineno">   20</span><span class="comment"></span> </div>
<div class="line"><a id="l00021" name="l00021"></a><span class="lineno">   21</span><span class="comment">/**</span></div>
<div class="line"><a id="l00022" name="l00022"></a><span class="lineno">   22</span><span class="comment"> * Modules for SHared Memory (SHM) support.  At a high level ipc::shm is a collection of sub-modules, each</span></div>
<div class="line"><a id="l00023" name="l00023"></a><span class="lineno">   23</span><span class="comment"> * known as a *SHM-provider*, as of this writing most prominently ipc::shm::classic and ipc::shm::arena_lend::jemalloc;</span></div>
<div class="line"><a id="l00024" name="l00024"></a><span class="lineno">   24</span><span class="comment"> * plus provider-agnostic support for SHM-stored native-C++ STL-compliant data structures.  See the doc headers</span></div>
<div class="line"><a id="l00025" name="l00025"></a><span class="lineno">   25</span><span class="comment"> * for each sub-namespace for further information.</span></div>
<div class="line"><a id="l00026" name="l00026"></a><span class="lineno">   26</span><span class="comment"> *</span></div>
<div class="line"><a id="l00027" name="l00027"></a><span class="lineno">   27</span><span class="comment"> * That said here&#39;s an overview.</span></div>
<div class="line"><a id="l00028" name="l00028"></a><span class="lineno">   28</span><span class="comment"> *</span></div>
<div class="line"><a id="l00029" name="l00029"></a><span class="lineno">   29</span><span class="comment"> * ### SHM-providers (ipc::shm::classic, ipc::shm::arena_lend) ###</span></div>
<div class="line"><a id="l00030" name="l00030"></a><span class="lineno">   30</span><span class="comment"> * Generally speaking there are two approaches to making use of ipc::shm:</span></div>
<div class="line"><a id="l00031" name="l00031"></a><span class="lineno">   31</span><span class="comment"> *   -# directly; or</span></div>
<div class="line"><a id="l00032" name="l00032"></a><span class="lineno">   32</span><span class="comment"> *   -# via ipc::session.</span></div>
<div class="line"><a id="l00033" name="l00033"></a><span class="lineno">   33</span><span class="comment"> *</span></div>
<div class="line"><a id="l00034" name="l00034"></a><span class="lineno">   34</span><span class="comment"> * While there are applications for approach 1, approach 2 is best by default.  It makes the setup</span></div>
<div class="line"><a id="l00035" name="l00035"></a><span class="lineno">   35</span><span class="comment"> * of a SHM environment far, far easier -- it is essentially done for you, with many painful details such as</span></div>
<div class="line"><a id="l00036" name="l00036"></a><span class="lineno">   36</span><span class="comment"> * naming and cleanup (whether after graceful exit or otherwise) taken care of without your input.  Furthermore</span></div>
<div class="line"><a id="l00037" name="l00037"></a><span class="lineno">   37</span><span class="comment"> * it standardizes APIs in such a way as to make it possible to swap between the available SHM-providers without</span></div>
<div class="line"><a id="l00038" name="l00038"></a><span class="lineno">   38</span><span class="comment"> * changing code.   (There are some exceptions to this; they are well explained in docs.)</span></div>
<div class="line"><a id="l00039" name="l00039"></a><span class="lineno">   39</span><span class="comment"> *</span></div>
<div class="line"><a id="l00040" name="l00040"></a><span class="lineno">   40</span><span class="comment"> * Regardless of approach, you will need to choose which SHM-provider to use for your application. I (ygoldfel) would</span></div>
<div class="line"><a id="l00041" name="l00041"></a><span class="lineno">   41</span><span class="comment"> * informally recommend looking at it from the angle of approach 2, as the ipc::session paradigm might clarify</span></div>
<div class="line"><a id="l00042" name="l00042"></a><span class="lineno">   42</span><span class="comment"> * the high-level differences between the SHM-providers.  I will now *briefly* describe and contrast the</span></div>
<div class="line"><a id="l00043" name="l00043"></a><span class="lineno">   43</span><span class="comment"> * SHM-providers.</span></div>
<div class="line"><a id="l00044" name="l00044"></a><span class="lineno">   44</span><span class="comment"> *</span></div>
<div class="line"><a id="l00045" name="l00045"></a><span class="lineno">   45</span><span class="comment"> * As of this writing there are two known types of SHM-providers: *arena-sharing* and *arena-lending*, of which</span></div>
<div class="line"><a id="l00046" name="l00046"></a><span class="lineno">   46</span><span class="comment"> * only the latter is formalized in terms of its general properties.</span></div>
<div class="line"><a id="l00047" name="l00047"></a><span class="lineno">   47</span><span class="comment"> *   - Arena-sharing: We have just one such SHM-provider available as of this writing: shm::classic (SHM-classic;</span></div>
<div class="line"><a id="l00048" name="l00048"></a><span class="lineno">   48</span><span class="comment"> *     boost.ipc-SHM; boost.interprocess-SHM).  In brief: it&#39;s built around shm::classic::Pool_arena, a single-pool</span></div>
<div class="line"><a id="l00049" name="l00049"></a><span class="lineno">   49</span><span class="comment"> *     thin wrapper around an OS SHM object (pool) handle with a boost.ipc-supplied simple memory allocation algorithm.</span></div>
<div class="line"><a id="l00050" name="l00050"></a><span class="lineno">   50</span><span class="comment"> *     Both processes in an IPC conversation (session) share one SHM arena (in this case consisting of 1 pool); both</span></div>
<div class="line"><a id="l00051" name="l00051"></a><span class="lineno">   51</span><span class="comment"> *     can allocate in that shared arena and cross-deallocate.  Internally auto-deallocation is handled via an atomic</span></div>
<div class="line"><a id="l00052" name="l00052"></a><span class="lineno">   52</span><span class="comment"> *     ref-count stored directly in the same SHM arena as the allocated object.  Due to SHM-classic&#39;s intentional</span></div>
<div class="line"><a id="l00053" name="l00053"></a><span class="lineno">   53</span><span class="comment"> *     simplicity, the lend/borrow aspects of it (where side/process 1 of a session *lends* a SHM-allocated object to</span></div>
<div class="line"><a id="l00054" name="l00054"></a><span class="lineno">   54</span><span class="comment"> *     side/process 2 which *borrows* it, thus incrementing the conceptual cross-process ref-count to 2) are</span></div>
<div class="line"><a id="l00055" name="l00055"></a><span class="lineno">   55</span><span class="comment"> *     properties of the arena-object `Pool_arena` itself.</span></div>
<div class="line"><a id="l00056" name="l00056"></a><span class="lineno">   56</span><span class="comment"> *   - Arena-lending: We have one SHM-provider as of this writing: shm::arena_lend::jemalloc; it is an application</span></div>
<div class="line"><a id="l00057" name="l00057"></a><span class="lineno">   57</span><span class="comment"> *     of the formalized arena-lending-SHM-provider paradigm specifically to the commercial-grade</span></div>
<div class="line"><a id="l00058" name="l00058"></a><span class="lineno">   58</span><span class="comment"> *     3rd party open-source `malloc()` provider (memory manager): [jemalloc](https://jemalloc.net).  It could be</span></div>
<div class="line"><a id="l00059" name="l00059"></a><span class="lineno">   59</span><span class="comment"> *     applied to other memory managers; e.g., tcmalloc.  (At the moment we feel jemalloc is easily the most</span></div>
<div class="line"><a id="l00060" name="l00060"></a><span class="lineno">   60</span><span class="comment"> *     performant and customizable open-source `malloc()`er around.)  Generally the memory-manager-agnostic aspects</span></div>
<div class="line"><a id="l00061" name="l00061"></a><span class="lineno">   61</span><span class="comment"> *     live in shm::arena_lend; while the SHM-jemalloc-specific ones go into shm::arena_lend::jemalloc.</span></div>
<div class="line"><a id="l00062" name="l00062"></a><span class="lineno">   62</span><span class="comment"> *     A major aspect of arena-lending SHM-providers is the separation of the the arena from the lend/borrow</span></div>
<div class="line"><a id="l00063" name="l00063"></a><span class="lineno">   63</span><span class="comment"> *     engine (SHM-session).  (Those aspects live in session::shm::arena_lend and session::shm::arena_lend::jemalloc;</span></div>
<div class="line"><a id="l00064" name="l00064"></a><span class="lineno">   64</span><span class="comment"> *     again, the memory-manager-agnostic and -non-agnostic aspects respectively.)  With an arena-lending SHM-provider,</span></div>
<div class="line"><a id="l00065" name="l00065"></a><span class="lineno">   65</span><span class="comment"> *     *each* of the two processes in a session creates/maintains its own arena, in which the other side cannot</span></div>
<div class="line"><a id="l00066" name="l00066"></a><span class="lineno">   66</span><span class="comment"> *     allocate; then via the session object the other side *borrows* an allocated object which it can at least</span></div>
<div class="line"><a id="l00067" name="l00067"></a><span class="lineno">   67</span><span class="comment"> *     read (but not deallocate; and by default not write-to).  Thus process 1 maintains a Jemalloc-managed arena;</span></div>
<div class="line"><a id="l00068" name="l00068"></a><span class="lineno">   68</span><span class="comment"> *     process 2 borrows objects from it and reads them; and conversely process 2 maintains a Jemalloc-managed arena;</span></div>
<div class="line"><a id="l00069" name="l00069"></a><span class="lineno">   69</span><span class="comment"> *     process 1 borrows objects from it and reads them.  Hence there are 2 process-local *SHM-arenas* and 1</span></div>
<div class="line"><a id="l00070" name="l00070"></a><span class="lineno">   70</span><span class="comment"> *     *SHM-session* for bidirectional lending/borrowing.</span></div>
<div class="line"><a id="l00071" name="l00071"></a><span class="lineno">   71</span><span class="comment"> *</span></div>
<div class="line"><a id="l00072" name="l00072"></a><span class="lineno">   72</span><span class="comment"> * shm::classic is deliberately minimalistic.  As a result it is very fast around setup (which involves, simply,</span></div>
<div class="line"><a id="l00073" name="l00073"></a><span class="lineno">   73</span><span class="comment"> * an OS SHM-open operation on each side) and around lend/borrow time (when a process wants to share a SHM-stored datum</span></div>
<div class="line"><a id="l00074" name="l00074"></a><span class="lineno">   74</span><span class="comment"> * with another process).  The negatives are:</span></div>
<div class="line"><a id="l00075" name="l00075"></a><span class="lineno">   75</span><span class="comment"> *   - It is not (and would be -- at best -- extremely difficult to become)</span></div>
<div class="line"><a id="l00076" name="l00076"></a><span class="lineno">   76</span><span class="comment"> *     integrated with a commercial-grade memory manager, with features such as anti-fragmentation and thread-caching;</span></div>
<div class="line"><a id="l00077" name="l00077"></a><span class="lineno">   77</span><span class="comment"> *     hence the allocation/deallocation of objects may be slower compared to heap-based over time.  We rely on</span></div>
<div class="line"><a id="l00078" name="l00078"></a><span class="lineno">   78</span><span class="comment"> *     boost.ipcs&#39;s algorithm which lacks the maturity of a jemalloc; and while a custom one could surely replace it,</span></div>
<div class="line"><a id="l00079" name="l00079"></a><span class="lineno">   79</span><span class="comment"> *     it would be challenging to improve-upon without bringing in a 3rd-party product; such products are not usually</span></div>
<div class="line"><a id="l00080" name="l00080"></a><span class="lineno">   80</span><span class="comment"> *     designed around being placed *entirely* into shared memory.</span></div>
<div class="line"><a id="l00081" name="l00081"></a><span class="lineno">   81</span><span class="comment"> *   - Two processes (at least) intensively write to the same memory area; this in the presence of</span></div>
<div class="line"><a id="l00082" name="l00082"></a><span class="lineno">   82</span><span class="comment"> *     crashing/zombifying/bugs -- where one process goes bad, while others are fine -- increases entropy and</span></div>
<div class="line"><a id="l00083" name="l00083"></a><span class="lineno">   83</span><span class="comment"> *     complicates recovery.  If process X of multiple co-sharing processes goes down or is ill, the entirety</span></div>
<div class="line"><a id="l00084" name="l00084"></a><span class="lineno">   84</span><span class="comment"> *     of the SHM-stored data in this system is suspect and should probably be freed, all algorithms restarted.</span></div>
<div class="line"><a id="l00085" name="l00085"></a><span class="lineno">   85</span><span class="comment"> *</span></div>
<div class="line"><a id="l00086" name="l00086"></a><span class="lineno">   86</span><span class="comment"> * There are no particular plans to make shm::classic more sophisticated or to formalize its type (&quot;arena-sharing&quot;) to</span></div>
<div class="line"><a id="l00087" name="l00087"></a><span class="lineno">   87</span><span class="comment"> * be extensible to more variations.  It fulfills its purpose; and in fact it may be suitable for many applications.</span></div>
<div class="line"><a id="l00088" name="l00088"></a><span class="lineno">   88</span><span class="comment"> *</span></div>
<div class="line"><a id="l00089" name="l00089"></a><span class="lineno">   89</span><span class="comment"> * In contrast shm::arena_lend is sophisticated.  A process creates an *arena* (or arenas);</span></div>
<div class="line"><a id="l00090" name="l00090"></a><span class="lineno">   90</span><span class="comment"> * one can allocate objects in arenas.  A real memory manager is in charge of the mechanics of allocation; except</span></div>
<div class="line"><a id="l00091" name="l00091"></a><span class="lineno">   91</span><span class="comment"> * when it would normally just `mmap()` a vaddr space for local heap use, it instead executes our internal hooks that</span></div>
<div class="line"><a id="l00092" name="l00092"></a><span class="lineno">   92</span><span class="comment"> * `mmap()` to a SHM-pool; SHM-pools are created and destroyed as needed.</span></div>
<div class="line"><a id="l00093" name="l00093"></a><span class="lineno">   93</span><span class="comment"> *</span></div>
<div class="line"><a id="l00094" name="l00094"></a><span class="lineno">   94</span><span class="comment"> * The other process might do the same.  It, thus, maintains its own memory manager, for allocations in SHM invoked</span></div>
<div class="line"><a id="l00095" name="l00095"></a><span class="lineno">   95</span><span class="comment"> * from that process.  Without further action, the two managers and the arenas they maintain are independent and only</span></div>
<div class="line"><a id="l00096" name="l00096"></a><span class="lineno">   96</span><span class="comment"> * touched by their respective processes.</span></div>
<div class="line"><a id="l00097" name="l00097"></a><span class="lineno">   97</span><span class="comment"> *</span></div>
<div class="line"><a id="l00098" name="l00098"></a><span class="lineno">   98</span><span class="comment"> * To be useful for IPC one would share the objects between the processes.  To be able to do</span></div>
<div class="line"><a id="l00099" name="l00099"></a><span class="lineno">   99</span><span class="comment"> * so, during setup each process establishes a *SHM-session* to the other process (multiple</span></div>
<div class="line"><a id="l00100" name="l00100"></a><span class="lineno">  100</span><span class="comment"> * sessions if talking to multiple processes).  Then one registers each local arena with a</span></div>
<div class="line"><a id="l00101" name="l00101"></a><span class="lineno">  101</span><span class="comment"> * SHM-session; this means objects from that arena can be sent to the process on the opposing side of the SHM-session.</span></div>
<div class="line"><a id="l00102" name="l00102"></a><span class="lineno">  102</span><span class="comment"> * From that point on, any object constructed in a given arena can be *lent* (sent) to any process on the opposing</span></div>
<div class="line"><a id="l00103" name="l00103"></a><span class="lineno">  103</span><span class="comment"> * side of a session with which that given arena has been registered.  This negates the negatives of SHM-classic:</span></div>
<div class="line"><a id="l00104" name="l00104"></a><span class="lineno">  104</span><span class="comment"> *   - A commercial-grade memory manager efficiently manages the in-SHM heap.  If you trust the performance of your</span></div>
<div class="line"><a id="l00105" name="l00105"></a><span class="lineno">  105</span><span class="comment"> *     regular `malloc()`/`new`/etc., then you can trust this equally.</span></div>
<div class="line"><a id="l00106" name="l00106"></a><span class="lineno">  106</span><span class="comment"> *   - Process 1 does not write to (or at least does not allocate in) a pool managed by process 2; and vice versa.</span></div>
<div class="line"><a id="l00107" name="l00107"></a><span class="lineno">  107</span><span class="comment"> *     Hence if process X goes down or is ill, the arenas created by the other processes in the system can continue</span></div>
<div class="line"><a id="l00108" name="l00108"></a><span class="lineno">  108</span><span class="comment"> *     safely.</span></div>
<div class="line"><a id="l00109" name="l00109"></a><span class="lineno">  109</span><span class="comment"> * The negatives are a large increase in complexity and novelty; and possible risks of sporadically increased latency</span></div>
<div class="line"><a id="l00110" name="l00110"></a><span class="lineno">  110</span><span class="comment"> * when SHM-allocating (as, internally, SHM-pool collections must be synchronized across session-connected processes)</span></div>
<div class="line"><a id="l00111" name="l00111"></a><span class="lineno">  111</span><span class="comment"> * and during setup (as, during the initial arena-lend one may need to communicate a large built-up SHM-pool</span></div>
<div class="line"><a id="l00112" name="l00112"></a><span class="lineno">  112</span><span class="comment"> * collection).  Just to set up a session, one must provide an ipc::transport::struc::Channel for</span></div>
<div class="line"><a id="l00113" name="l00113"></a><span class="lineno">  113</span><span class="comment"> * the SHM-session&#39;s internal use to synchronize pool collections and more.</span></div>
<div class="line"><a id="l00114" name="l00114"></a><span class="lineno">  114</span><span class="comment"> *</span></div>
<div class="line"><a id="l00115" name="l00115"></a><span class="lineno">  115</span><span class="comment"> * Lastly, as it stands, the arena-lending paradigm does lack one capability of SHM-classic; it is fairly</span></div>
<div class="line"><a id="l00116" name="l00116"></a><span class="lineno">  116</span><span class="comment"> * advanced and may or may not come up as an actual problem:</span></div>
<div class="line"><a id="l00117" name="l00117"></a><span class="lineno">  117</span><span class="comment"> *</span></div>
<div class="line"><a id="l00118" name="l00118"></a><span class="lineno">  118</span><span class="comment"> * Imagine long-lived application A and relatively short-lived application B, with (say) serially appearing/ending</span></div>
<div class="line"><a id="l00119" name="l00119"></a><span class="lineno">  119</span><span class="comment"> * processes B1, B2, B3 in chronological order.  A can allocate and fill an object X1 while B1 is alive; it will</span></div>
<div class="line"><a id="l00120" name="l00120"></a><span class="lineno">  120</span><span class="comment"> * persist even after B1 dies and through B2 and B3; B1 through B3 can all read it.  But can B1 *itself* do so?</span></div>
<div class="line"><a id="l00121" name="l00121"></a><span class="lineno">  121</span><span class="comment"> *   - With shm::classic: Yes.  It&#39;s all one arena shared by everyone, readable and writable and allocatable by all.</span></div>
<div class="line"><a id="l00122" name="l00122"></a><span class="lineno">  122</span><span class="comment"> *   - With shm::arena_lend: No.  Anything B1 allocates, by definition, must disappear once B1 exits.  The entire</span></div>
<div class="line"><a id="l00123" name="l00123"></a><span class="lineno">  123</span><span class="comment"> *     arena disappears by the time B2 appears.  B2 can read anything that *A* allocated including before B2 was</span></div>
<div class="line"><a id="l00124" name="l00124"></a><span class="lineno">  124</span><span class="comment"> *     born, because A is alive as is the arena it maintains; but B1 -- no.</span></div>
<div class="line"><a id="l00125" name="l00125"></a><span class="lineno">  125</span><span class="comment"> * In the ipc::session paradigm this type of data is known as *app-scope* in contrast to most data which are</span></div>
<div class="line"><a id="l00126" name="l00126"></a><span class="lineno">  126</span><span class="comment"> * *session-scope*.  For data relevant only to each conversation A-B1, A-B2, A-B3, there is no asymmetry: Internally</span></div>
<div class="line"><a id="l00127" name="l00127"></a><span class="lineno">  127</span><span class="comment"> * there are 2 arenas in each of the 3 sessions, but conceptually it might as well be a 1 common arena, since both</span></div>
<div class="line"><a id="l00128" name="l00128"></a><span class="lineno">  128</span><span class="comment"> * sides have symmetrical capabilities (allocate, read/write, lend; borrow, read).  So for session-scope data</span></div>
<div class="line"><a id="l00129" name="l00129"></a><span class="lineno">  129</span><span class="comment"> * shm::classic and shm::arena_lend are identical.</span></div>
<div class="line"><a id="l00130" name="l00130"></a><span class="lineno">  130</span><span class="comment"> *</span></div>
<div class="line"><a id="l00131" name="l00131"></a><span class="lineno">  131</span><span class="comment"> * ### STL support ###</span></div>
<div class="line"><a id="l00132" name="l00132"></a><span class="lineno">  132</span><span class="comment"> * The other major sub-module, as mentioned, is agnostic to the specific SHM-provider.  It allows one to store</span></div>
<div class="line"><a id="l00133" name="l00133"></a><span class="lineno">  133</span><span class="comment"> * complex native C++ data directly in SHM.  Namely, arbitrary combinations of STL-compliant containers, `struct`s,</span></div>
<div class="line"><a id="l00134" name="l00134"></a><span class="lineno">  134</span><span class="comment"> * fixed-length arrays, scalars, and even pointers are supported.  Both SHM-providers above (shm::classic and</span></div>
<div class="line"><a id="l00135" name="l00135"></a><span class="lineno">  135</span><span class="comment"> * shm::arena_lend::jemalloc) provide the semantics required to correctly plug-in to this system.  See doc header</span></div>
<div class="line"><a id="l00136" name="l00136"></a><span class="lineno">  136</span><span class="comment"> * for namespace shm::stl to continue exploring this topic.</span></div>
<div class="line"><a id="l00137" name="l00137"></a><span class="lineno">  137</span><span class="comment"> */</span></div>
<div class="line"><a id="l00138" name="l00138"></a><span class="lineno">  138</span><span class="keyword">namespace </span><a class="code hl_namespace" href="namespaceipc_1_1shm.html">ipc::shm</a></div>
<div class="line"><a id="l00139" name="l00139"></a><span class="lineno">  139</span>{</div>
<div class="line"><a id="l00140" name="l00140"></a><span class="lineno">  140</span> </div>
<div class="line"><a id="l00141" name="l00141"></a><span class="lineno">  141</span><span class="comment">// Types.</span></div>
<div class="line"><a id="l00142" name="l00142"></a><span class="lineno">  142</span> </div>
<div class="line"><a id="l00143" name="l00143"></a><span class="lineno">  143</span><span class="comment">// Find doc headers near the bodies of these compound types.</span></div>
<div class="line"><a id="l00144" name="l00144"></a><span class="lineno">  144</span> </div>
<div class="line"><a id="l00145" name="l00145"></a><span class="lineno">  145</span><span class="keyword">template</span>&lt;<span class="keyword">typename</span> Arena&gt;</div>
<div class="line"><a id="l00146" name="l00146"></a><span class="lineno">  146</span><span class="keyword">struct </span>Arena_to_borrower_allocator_arena;</div>
<div class="line"><a id="l00147" name="l00147"></a><span class="lineno">  147</span> </div>
<div class="line"><a id="l00148" name="l00148"></a><span class="lineno">  148</span>} <span class="comment">// namespace ipc::shm</span></div>
<div class="ttc" id="anamespaceipc_1_1shm_html"><div class="ttname"><a href="namespaceipc_1_1shm.html">ipc::shm</a></div><div class="ttdoc">Modules for SHared Memory (SHM) support.</div><div class="ttdef"><b>Definition:</b> <a href="shm_2classic_2classic_8hpp_source.html#l00025">classic.hpp:26</a></div></div>
</div><!-- fragment --></div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated on Fri Apr 11 2025 20:02:26 for Flow-IPC by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.4
</small></address>
</body>
</html>
